4章　区切られた文脈どうしの連係

契約が必要な理由は、異なる区切られた文脈どうしでは、モデルと言葉が異なるため、取り決めを明文化しお互いの利害関係を調整するために必要

区切られた文脈にはそれぞれ、同じ言葉が存在するケースが有り、連携する場合どちらの文脈の言葉を使えばよいか迷うケースが有る

契約を使った連携方法を学ぶ

緊密な協力

異なる区切られた文脈を複数のチームで開発を行う際に重要なのは、チーム間の意図の伝達と協力の質

質を高める際の観点として以下の2つがある

良きパートナー

モデルの共有

良きパートナー

区切られた文脈どうしを連携させるために、修正内容を他のチームに共有し、整合できるようそのチームは変更に対応する

この協力関係は双方向であるべき

協力関係を築くためには、目標の共有と達成に対する強い意志が必要

物理的に離れたチームどうしでは関係を築く難易度が高まるため、工夫が必要

オンラインでもシームレスにコミュニケーションを取れる環境づくり

モデルの共有

区切られた文脈はモデルの境界だが、場合によっては複数の区切られた文脈で同じモデルをを実装することがある

これがモデルの共有(Shared Kernel)

共有部分は、関係するすべての区切られた文脈の要求に基づいて設計することができるため、かなり重要

共有されたモデルは、それを使うすべての文脈と整合する必要がある

独自の認可モデルを全システムで使う場合

https://scrapbox.io/files/68fda1d6c32924f2fa8c7f7a.png

共有する範囲

複数の文脈にも同様の実装が必要となった場合に限定して、共有する

共有するモデルの対象は、連携するための契約と境界を超えて渡すデータ構造のみにする

共有の仕方

単一リポジトリ

同じソースコードを利用する

分離されているリポジトリ

共有するモデルをモジュール化する

共有しているモデルを変更したら、利用側は即座に変更を反映し、結合テストで整合できていることを担保する

code:php

// 共有される値オブジェクト

namespace SharedKernel;

class Money

{

public function __construct(

private int $amount,

private Currency $currency

) {}

}

モデル共有の判断

コードの重複により発生するコストと、共有するコストの対比で判断する

また、モデルの変更頻度にもよる

頻繁に変更が入るモデルは、重複による変更コストが大きいため、共有したほうが良いケースが多い

利用者と供給者の関係

https://scrapbox.io/files/68fda679c32924f2fa8c906e.png

力関係によって以下の3つの連携方法がある

従属

モデル変換装置

共有サービス

従属

サービスを利用する側が、サービスを提供する側のモデルに合わせる

上流への影響力がない場合に使用

https://scrapbox.io/files/68fda8b04101fb0a2aa808c2.png

サービスを利用する側が、サービスを提供する側のモデルを自分のモデルに合うように変換する

https://scrapbox.io/files/68fda8e1c32924f2fa8c99e9.png

以下のようなケースの場合は、モデル変換装置を使うのが好ましい

下流の文脈が中核の業務領域を含んでいる

重要である中核の業務領域が上流のモデルに引きずられないようにするため

上流のモデルが使いづらい場合

上流のモデルが頻繁に変更される場合

外部システムのデータを独自のモデルに変換するイメージ

サービスを提供する側が、標準化されたプロトコル(REST API、gRPC)で複数の下流の文脈にサービスを提供する

この際に公開された言葉としてデータのフォーマット(JSONなど)は固定する必要がある

https://scrapbox.io/files/68fda9d7ab06538fd290c3f5.png

APIのバージョン管理がこれに当たる

モデルを共有しない方が良いケース

意思疎通にコストがかかる

組織が大きい場合、部門間で利害が対立している場合は、複数の区切られた文脈で同じ機能を重複して開発したほうが費用対効果が高い

業務領域が他社と差別化を図らなくても良い、一般的な業務かつ、一般的な解決手段を簡単に組み込めるなら、それぞれ区切られた文脈ごとに、手軽な解決手段を取り入れるほうが費用対効果が高い

ex

ログ出力ようのロギングフレームワーク

共通のロギング機能を自作して提供するより、各々既存のフレームワークを使ったほうが簡単

文脈の地図を作る

全体的な設計

どのようなコンポーネント、コンポーネントが実装するモデルがシステムにどう関わっているのか把握できる

意図の伝わり方

文脈やモデルどうしの関係性を視覚的に、チームをまたいで共有できる

組織上の課題

上流チームと下流チームの関係性が明確になるため、組織的課題が特定できる